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(54) Method for addressing a bit stream recording 

(57) In bitstream recording presentation data is 
organised into Video Object Units. These have a varia- 
ble size but have also a variable duration. To allow 
access to any Video Object Unit in the bitstream a 
housekeeping address table is used which is based on 

pieces (VOBU#n) of the bitstream of constant size per - 

piece. The address table additionally contains for each D A V 

of these pieces a specific delta duration (ADUR#n) 
which indicates the arrival time difference between the 
last and the first packet contained in a piece. The com- 
putation of the target VOBU address includes the follow- 
ing steps: 

- accumulate the delta durations until the given time 
value is most closely reached towards the target 
VOBU; 

the running index of this table entry multiplied by 
the constant piece size directly results in the 
address value to be accessed. 
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Description 

[0001] The invention relates to a method and to an apparatus for addressing a bitstream to be recorded or being 
recorded on a storage medium, e.g. an optical disc. 

5 

Background 

[0002] In bitstream recording one is free to subdivide the bitstream into sub-units of more regular structure. Pres- 
entation data in DVDs (digital video or versatile disc) is organised into units called Video Object Unit, denoted VOBU, 
w e.g. in the RTRW Specification for Realtime Rewritable Video DVDs. VOBUs have a variable size (data amount meas- 
ured in number of sectors), but have also a variable duration (measured in number of video fields). 
For data retrieval from the disc the RTRW specification foresees a VOBU map' which is a table where for every VOBU 
in a recording the length in sectors and the duration in fields is entered. 

is Invention 

[0003] A table for data retrieval from a storage medium can be based on bitstream data being subdivided into 
pieces of constant duration. 'Duration' means the difference between the arrival time of the last packet of a piece and 
the arrival time of the first packet of that piece. 
20 'Housekeeping' in the general context of either RTRW recording or Stream recording is the task to translate a given time 
value (presentation time in case of RTRW recording or packet arrival time in case of Stream recording) into a disc 
address value where the desired data can be found. 

[0004] In such systems the VOBU map or 'housekeeping address table', denoted HAT, can contain a specific size 
or a specific offset or a specific delta size or, in general, a specific address-like quantity for each of these constant-dura- 
25 tion pieces. By storing delta values instead of the total duration at a current VOBU these entries can be described with 
shorter word length which helps to keep the total VOBU map in a reasonable size. 
A possible type of housekeeping process for these systems could include the following steps: 

By division and truncation, calculate from the given time value the index of the table entry to be looked up. 
30 - The content of the table entry either directly specifies the address value to access, or all table entries up to that 
index have to be accumulated to get the address value to be accessed. 

[0005] The big disadvantage of such type of HAT which is based on constant-duration pieces lies in the following: 

35 - In case of a low bitrate recording the pieces of constant duration will be small in size, i.e. every piece will comprise 
a few data sectors only or, in the extreme, a fraction of a data sector only. The disc can contain enormous numbers 
of those pieces, so that the HAT may become too big to be kept in the memory. 

In case of high bitrate recording, the pieces of constant duration are big in size, i.e. each piece will comprise many 
data sectors. Then, addressing one piece or another corresponds to a very coarse addressing on the (sector) 
40 scale, i.e. a piece address derived from the HAT can be located many sectors away from the currently desired loca- 
tion. 

[0006] Therefore housekeeping based on constant-duration pieces can result in a too big HAT in some cases (up 
to one half of the disc capacity), and can result in too coarse addressing in other cases. 
45 [0007] It is one object of the invention to disclose a method for assigning to a given time value a storage medium 
address value which method avoids such disadvantages. This object is achieved by the method disclosed in claim 1 . 
[0008] According to~the invention the housekeeping address table HAT is based on pieces of constant length or 
size, i.e. a constant number of bits per piece. 

in a medium like DVD-RAM where data are physically organised into 'ECC blocks' (ECC: error correction code) of 
so 32kByte length each, particular advantages result if the above constant size or a multiple of it is used as the constant 
size of a piece. However, any other constant size can be used. In this case of pieces of constant size the HAT contains 
for each of these pieces of constant size a specific absolute duration or, preferably, a specific delta duration which indi- 
cates the arrival time difference between the last and the first packet contained in a piece. 
The housekeeping process, i.e. the computation of the target VOBU address includes the following steps: 

55 

Accumulate the delta durations contained in the HAT until the given time value is most closely reached towards the 
target VOBU, i.e. until the sum of delta durations is less than or equal to the given time value assuming that forward 
scanning of the VOBU entries is performed, or until the sum of delta durations is greater than or equal to the given 
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time value assuming that backward scanning of the VOBU entries is performed. 
" Messed" 9 ind6X ° f * hiS t3ble mUltiP ' ied by thS C ° nStant PiSCe SiZ6 direct,y results in the address value to be 
s [0009] The advantages of the inventive constant-size based HAT are: 
- the HAT size does not depend on the bitrate of the recordings 

" ?„ hf^? eSSin9 aCCUraCy iS ° 0nStant the 9 ranularit y basical| y corresponds to the 'piece size constant' which 

» SX^iKST to be mM for a " *- of discs - 10 be ronstant per disc - or to be constant 

S?l 01 J? principle ' tne inventive method is suit ed for addressing a bitstream to be recorded or being recorded on a 
wSn ' 3 reCOrder • Wh6rein 3n addr6SS t3b,e iS US8d •* is based on P jeces ° f said 9 bStrLam and 
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said pieces each include a constant amount of bits of said bitstream- 

SS^ST 8 tab,e ^ 30 abSO ' Ute time duratlon 0r 8 delta time duration is a ^ned in said 

address tabte using a running index; M 

in case of absolute time duration values storage: in order to get an address value for reaching a target address the 

Z TSZ" 9 TSU timS dUrati ° n ^ ° f 8Bld addr6SS tab,e is Selected and the corresponding run 
n.ng index becomes mult.pi.ed by said constant amount in order to compute said address value or 

in case of delta time duration values storage: in order to get an address value for reaching a target address all delta 

t,me durafcons up to the nearest time duration corresponding to said address value become accumuiaS and the 

SSS ^cSTE?" 8 1° th6 H d6l : a dUrati ° n 6ntry r6,ated 10 Said near6St time ^ratirbeSmes mut 
plied by said constant amount in order to compute said address value. 

claims 1 Advanta9eOUS additional embodiments of the inventive method are disclosed in the respective dependent 

so Drawings 

[0012] Embodiments of the invention are described with reference to the accompanying drawings, which show in: 

Fig. 1 simplified overall system for DVD Stream Recording; 

35 Fig. 2 basic directory and file structure; 

Fig. 3 navigation data structure; 

Fig. 4 stream pack; 

Fig. 5 inventive housekeeping address table; 

Fig. 6 Stream Time Map Information; 

*o Fig. 7 mapping list example. 

Exemplary embodiments 

[0013] The DVD Stream Recording system is designed to use rewritable DVD discs for recording existina digital bit- 

ST"! f t,n K 9 ; hem 3nd Playin 9 them back as learns. The following abbreviations are vZSTSS^ 

ta^eo^ R T T*™ ^ POSiti ° n ' RLBN: re,ative block ^B: set top'box TOO- 

table of content, SCR; system clock reference. K ^ 

[0014] This system is designed to satisfy the following requirements- 

Any packet size is supported as long as it is less than 2kByte and of constant length within a take 

back '" 9 meChan ' Sm - i & 3 time Stamp is added to bra ^cast packet to enable proper packet delivery during play- 

Data allocation strategy and file support real-time stream recording 

55 ^T a S y »^ 9 hw h^T 68 re Sf ? 6rViCe lnformation which normally is embedded in the real-time stream. To support a 
S 21 by rl ata fr ° m 3 Player " the should P rovWe Additional space, which can be used by the STB to d° pl^ 
cate part of the service information and to add additional TOC information P 

Copy Protection must be supported. In addition, any scrambling performed by the service provider or the STB must be 
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kept unchanged. 

User requirements can be grouped into requirements for recording, requirements for playback, and requirements for 
editing: 

5 Real-time Recording 

[001 5] The system should be designed to enable real-time recording of digital streams. It also should allow the user 
to concatenate recordings, even if those recordings consist of different stream formats. If recordings are concatenated, 
a seamless or close to seamless playback possibility would be nice but is not required. 

10 

Navigation Support 

[0016] To support navigation two pieces of information (lists) should be generated during recording: 

15 1) An 'original' version of a play list. This list contains quite low level information, e.g. time map or (broadcast) 
packet order of the recording. This list is accessible by the STB and the content is understood by the DVD streamer 
as well as by the STB. In its original version the playlist enables the playback of a complete recording. The playlist 
may be accessici and extended after recording by the STB to allow more sophisticated playback sequences. 
2) The second piece of information, a mapping list, is generated to support the stream recorder to retrieve packet 

20 stream chunks (cells), that are described in terms of the application domain, e.g. 'broadcast packets' or 'time'. This 
list is owned and understood by the DVD streamer only. 

Content Description 

25 [001 7] The system should reserve space which can be used by the STB to store high level TOC and Service Infor- 
mation. This information is provided for the user to navigate through the content stored on disc and may contain sophis- 
ticated GUI information. The content needs not to be understood by the stream recorder. However a common subset of 
the TOC information, e.g. based on a character string, may be useful to be shared between STB and DVD, in order to 
enable the stream recorder to provide a basic menu by itself. 

30 [0018] Playback of individual recording and playing all recordings sequentially should be possible via play list. 

Player menus for entry point selection 

[0019] The STB can generate a sophisticated menu based on the TOC information stored on the disc. However, it 
35 should be possible to generate a simple menu by the streamer itself, e.g. via some 'character' information which is 
shared by STB and DVD. 

Trick play modes 

40 [0020] The STB should be able to steer trick play via the 'play list'. Due to the nature of the broadcast stream, the 
trick play features may be limited to basic ones, e.g. Time Search and Title Jump. 

User defined playback sequence features like programming or parental control can be supported via the play list 
[0021] The DVD streamer should create the 'original version' of the play list, it also should allow extensions and 
modifications of the play list by the STB for more sophisticated playback features. The DVD streamer is not responsible 
45 for the content of those sophisticated playlist(s). 

[0022] The system must support the deletion of single recordings on user's request. If possible, the system should 
allow this feature under the control of the STB. 
The system may support insert editing. 

[0023] In the simplified overall system of Fig. 1 an application device AD interacts via an interface IF, e.g. an 
so IEEE1394 interface, with a streamer device STRD, i.e. a DVD recorder. A streamer STR within STRD sends its data via 
output buffering & timestamping handling means BTHO to IF and receives from IF data via input buffering & timestamp- 
ing handling means BTHL AD sends its data via output buffering & timestamping handling means BTHOAD to IF and 
receives from IF data via input buffering & timestamping handling means BTHIAD. 

[0024] Concerning the directory and file structure, the organisation of Stream Data and Navigation Data of DVD 
55 Stream Recording is done in a specific way such as to take into account the following: 

Any DVD Streamer device STRD has certain requirements to store its own housekeeping data or Streamer-specific 
navigation data on the disc. These data are solely for helping the retrieval of recorded data; they need not be under- 
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stood or even be visible to any outside application device AD 
- Any DVD Streamer device STRD needs to communicate with the application device AD it is connected tn Thic 

»n?™£? m T , Nav,gatlon Data to su PP°rt s^h communication are called Common navigation date 
and must be understandable by the Streamer as well as by the application device navgation date 

" date IT S2E2l£rS *S" ° ffer t0 ^ C ° meCted aPP,iCati ° n d6ViCe AD 9 means for sto ™9 own private 
ofts°^ n0t to Und — d a ^ * tha intent, interna, struck, or meaning 

' S? 2 !? Z' 9 ' 2 illustrates a Possible directory and file structure where all the data comprising the dkr content „™ 

- COMMON. IFO 

s?ia C m^ rmati ° n t0 d6SCribe Str6am COntent Ne6dS *° be Understood * the device as well as the 

- STREAMER.IFO 

Pn^te housekeeping information specific to the Streamer Device. Needs not to be understood by the Application 

- APPLICAT.IFO 

SSSS^t^t^*" * *> »« "« to Sbeame,. Needs no, 

- REALTIME. SOB 

Recorded real-time stream data proper. 

d£Lm 6XCePt ^ fHeS deSCTibed ab0V€ - thS STRREC dir6Ct0ry sha " not contain W other files or 
I^ 2 ^itinn C ^Tn rn K n ^ the nav !f tion data structure - Navigation data is provided to control the recording playing back 

'nS^SSSS!; D ™H S ' ream Re<XMii " 9 foresMS me possibl1 *)' 01 * storage lo»«tlon tor Application 

eET APD ).**™y'"S»n e «l also be considered as Navigator. Data Application 

fr i*™^ ."m N "*"«?' Dal> are dreoav relevant for foe Slreamer operation. SMI includes three kinds 
of nbrmnon iMte, namely stream Manager General Information (SM Ql). Stream Title Table (STT1 ^^Zi 

S'""* f: HK T' Mu * s '»° 1 ** of informaL-Jes. n^SuS^aS^T 
matron (HKF_QI) and Housekeeping Address Table (HAT), in this order oenerai inror 

oou^Sy" 0 ,eStM °° '" ^ F,9CMn9 «" «•* Na "^°" '"tomtation must be aligned wifh a sector 

SddreTollpS 1 "* 8 '*™ fcn temS " kS en " a *" eSS «**«« X star, address of STT and 

Sr=<^s£^^ tscal) 01 h °^- 

Srtoe^n™ '"l^ema *~" ^ <SOBS ' "* " " ^ » ' *"*■» — 
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A SOB can be terminated by a program_end_code. The value of the SCR field in the first pack of each SOB may be 
non-zero. A SOB contains the Stream Data packed into a sequence of 'Stream Packs' (S_PCKs). Stream data can be 
organised as one elementary stream and are carried in PES packets with a streamjd. 

[0033] As shown in Fig. 4 a Stream Pack includes a pack header, eventually followed by a system header, and fol- 
5 lowed by one Stream Packet (S__PKT). A system header may be included in those S_PCKs which are the first S_PCK 
of a SOB. When a system header is included, the length of the remaining Stream Pack content is 2010 bytes, when it 
is not included, the length of Stream Pack content is 2034 bytes. 
[0034] A stream Object is composed of one or more Stream Packs. 

[0035] The HAT table depicted in Fig. 5 contains for each piece or VOBU (VOBU#1 to VOBU#n) of the bitstream to 
10 be recorded or of the recorded bitstream a corresponding absolute or delta time duration entry ADUR#1 to ADUR#n . 
DAC denotes a desired address or target address in the bitstream. VOBU#1 to VOBU#n each concern a constant 
number of bits of the bitstream. 

[0036] The HAT table can have the format of a Stream Time Map Information STMAPI and may include two sub- 
units: "Stream Time Map General Information" STMAP_GI and one "Mapping List" MAPL. A possible content of 
is STMAPI is shown in Fig. 6. MAPU_SZ describes the size in sectors of the mapping list units. A Mapping Unit Size of 
e.g. 1 6 sectors means that the first Mapping List Entry relates to the application packets contained in the first 1 6 sectors 
of the Stream, the second Mapping List Entry relates to the application packets contained in the next 16 sectors, and 
soon. 

MTLLSHFT describes the weight of the LSB of the mapping list entries, relative to the bits of the Packet Arrival Time 
20 (PAT) Describing Format. MTU_SHFT describes a value between 16 and 36. A value of e.g. "16" means that the LSB 
of Incremental Application Packet Arrival Time IAPAT has the same weight as PAT_base[0], whereby PATJ>ase[x] 
means a PAT base value measured by 90kHz units. 
MTU_SHFT depends on MAPU_SZ. MTU_SHFT fulfils the rules: 

25 ft , ccot - 0 34 MAPU SZ . i 

2 max bitiate 



30 



and 

16 < MTUJSHFT <> 36 

wherein 

35 maxjDitrate = maximum bitrate of the MPEG-2 Program Stream. 

[0037] MAPL_ENTJMs describes the number of Mapping List Entries to follow after STMAP_GI. 
S_S_APAT describes the start Application Packet Arrival Time of the Stream, i.e. the packet arrival time of the first 
packet belonging to the Stream. 
40 S_E_APAT describes the end Application Packet Arrival Time of the Stream, i.e. the packet arrival time of the last packet 
belonging to the Stream. 

[0038] The Mapping List MAPL consists of zero or more "Incremental Application Packet Arrival Times" IAPAT 
IAPAT describes the Incremental Application Packet Arrival Time of the corresponding Mapping Unit in DVD Stream 
Recording's Incremental PAT Describing Format defined in the following: 
45 Let MAPU_S_APAT(i), 1 < i < MAP L_E NT_Ns, be the start Application Packet Arrival Time of the Mapping Unit #i, i.e. 
the packet arrival time of the first packet belonging to the Mapping Unit #i; let MAPU_E_APAT(i) be the last Application 
Packet Arrival Time of the Mapping Unit #i, i.e. the packet arrival time of the last packet belonging to the Mapping Unit 
#i and let lAPAT(i) be the i-th IAPAT entry of the Mapping List, i.e. IAPAT(1) is the first entry of the Mapping List. Then 
lAPAT(i) shall fulfil the rules: 



50 



55 



0 < 



IAPAT (k) 

U=1 



MAPU_S_APAT(i+1) 1 

2 MTU_SHFT < 



for i m 1,2 MAP L_E NTJMs- 1 

and 
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0 < 



r ' 

^TlAPAT(k) 



L/c=1 



MAPU_ E_APA T ( i) 

2 MTU^SHFT ~ 1 



for i = MAPL_ENT_Ns , 
and 



0 < lAPAT(i) < 2 
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for i = 1,2, .... MAPL_ENTJ\ls . 

[0039] Fig. 7 shows an example of the order of MAPU, MAPU S APAT MAPU E APAT snrt I apat th. .~ 

ZpJTX^TJ^J^ UnjtS ^ the UPP6r SWe ° f *• " - the MAP^s ^ The s ' da 

S - ? U_E_APAT(i) are described in the DVD Stream Recording s PAT Describing Format For the 

comparison in the equation above MAPU S APATYi) and MAPU E APATYft aro tr^Ln o e ~"° ,ng TOrmat F ° r the 
values. The duration of I APAT = 1 is the " " MAPU_E_APAT(,) are treated as e.g. 6 byte unsigned integer 



0 MTU_SHFT 

Time Unit of IAPAT = £ seconds 

5625 -2 20 



The data stream also contains time stamps, e.g. within the data packets. 
Claims 

^^ZSS^^^SST^ t reC ° rded ° f bein9 r6COrded ° n 3 Stora9e medium < STRD >- "herein an 
address table (HAT) is used that is based on p.eces (VOBU#n) of said bitstream, characterised by: 

- said pieces (VOBU#n) each include a constant amount of bits of said bitstream- 

" Llnnl a fn d « S H en !l. f ° r "** PieC6S an abSOlute time duration or a del ^ ^e duration (ADUR#n) is 
assigned in said address table using a running index ( 1 2 3 n) ■ ' 

" E>2S2 abS0,U ? time dUrati ° n ValU6S St ° ra9e: in order t0 aet an address valu « for reaching a target address 
(DAV) the nearest corresponding absolute time duration entry (ADUR#i) of said address table fHAT?feX^ 

SSZT runnin9 index (i) becomes mu,tip,ied * said co " stant «^oSS 

" rnA^ S l?H? t lta t tim l dUrati0n ValU6S St ° ra9e: in ° rder to aet an address ^ reaching a target address 
£2U tl I medurat,ons ( A °UR#1. ... ADUR#i) up to the nearest time duration value coSpondinoS 

XtS*? SETLF 1 ^ and H the runnin9 index (i) corres pondin9 to ^5^12235 

ST e duration va,ue becomes muttip,ied by said constant a ™ nt in 

2. Method according to claim 1 , wherein said storage medium (STRD) is a Streamer device or a DVD recorder. 

3 ' tTmr^ a r rd 7 J ° °!? m 1 ° r 2 ' Wherei " Said Pieces (VOBU#n ) of *** Wtstream contain data packets and a delta 
time duration value is the arrival time difference between the last and the first data packet Snedt a plecf 

4 - itrrj^^^^ 
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